Думаю, каждый айтишник мечтает порой вернуться к истокам, где всё было прекрасно и инженерно. Я, вот, например, начинал с разработки железок и прошивок и периодически хочу к ним вернуться.

Кажется, что с железками сильно меньше неопределённости и хаоса, чем в энтерпрайзе. С оговорками, конечно, но, по крайней мере, в одно устройство физически невозможно впихнуть все хочушки бизнеса, придётся делать ещё одно. Впрочем, мой порыв обычно быстро затухает, когда товарищ присылает описания своих аппаратных багов.

И, как вы понимаете, это серьёзное дерьмо. Железка живёт где-то далеко в физическом мире. Новую версию на сервер не выложишь, оно уже китайцами собрано и у потребителя на руках. В лучшем случае можно выложить новую прошивку и надеяться, что владелец заморочается с микро-USB. А в худшем случае ничего не поделаешь, прибор будет работать через назад, если вообще не сдохнет. И к нему просто так не подключишься для диагностики, логи в облако он не пишет, вот это всё. А баги есть в любых устройствах. Вот, посмотрите, раздел ERRATA для STM32.

В итоге ошибки находятся в бесконечных экспериментах по воспроизведению симптомов и медитации на исходники прошивок. Это сушит мозги сильнее, чем разгребание слоёнки после джунов. В общем, занятие не для слабых духом.

Однако я порекомендовал бы поковырять железо каждому разрабу. Потому что это вам даст следующее:

- Понимание древних вед основ вычислительной техники. У простых микроконтроллеров элементарная архитектура, можно наблюдать их жизнь в реальном времени
- Глаза отдохнут от монитора
- Получите массу сенсорного опыта: понюхаете канифоль, обожжётесь об паяльник, пошевелите пальцами в ловле мелких деталей
- Сможете понять, как работают операционки. Можно взять FreeRTOS для Arduino и посмотреть, как работает многозадачность, переключаются контексты и т.д.
- Можно потренироваться в упражнении «Пойми, что отвалилось». Суть: вас есть больное устройство, и нужно понять, что с ним не так, и как исправить. При этом терминалом служит условный Олег, который говорит вам в телефон, что «зеленый огонёк мигает и ничего не работает». Гарантирую, что вы свои рабочие поделки в разрезе мониторинга увидите в новом свете
- Получить удовольствие от осознания, что ваш код шевелит чем-то в реальном мире. Мне это нравилось больше всего

На собеседованиях гоняют по теории, потому что не знают, что ещё спрашивать!

Как-то я прособеседовал 15 человек за неделю и понял, что соискатели сами виноваты в том, что их гоняют по дебрям теории и загадывают ребусы.

Смотрите, в чём дело.
Вот приходил чел писать высоконагруженный бэк. Мне нужно понять, насколько он хорош, поэтому я спрашиваю про опыт. Во-первых, пересказ Книги с Кабанчиком не гарантирует экспертности, а во-вторых конкретные случаи из практики соискателя дадут мне зацепки для дальнейшей беседы. Мы поговорим про технические решения, ограничения, зависимости всякие, и сразу станет понятно, насколько человек владеет мастерством.

Но обычно мало кто может внятно рассказать о своём опыте, разговор не клеится, оба сидят как дураки, и интервьювер тянется за списком типовых вопросов в духе «Назовите мне этапы инициализации контекста в спринге».

Как надо
Чтобы не тонуть на собеседовании, стоит говорить на знакомые вам темы. А для этого расскажите связную историю и расставьте триггеры в нужных местах, чтобы интервьювер спрашивал у вас то, что вы хотите рассказать. Например:

Я разработал архитектуру приложения, которое зарабатывало бизнесу 400к $ в месяц. Приложение интегрировалось с 7 разными глючными системами. Входная нагрузка была 100 rps, а мы генерировали в районе 500 rps к сторонним системам. Чтобы повысить надёжность, мы применяли асинхронную коммуникацию на кафке. А чтобы особенности интерфейсов этих систем не влияли на наш домен, мы использовали hexagonal architecture, вынеся всё взаимодействие в плагины.

Основные триггеры:
- 400к $ в месяц — вы сразу показали что не в игрушки игрались, а делали серьёзную систему, за простой которой начальство сильно спросит.
- 100/500 rps — показали цифрами, что для вас высокая нагрузка, а не пресловутые «высоконагруженные системы».
- Вдобавок тут огромное количество технических ништяков, которые нормальный интервьюер увидит, и вы проговорите про них оставшийся час:
- Hexagonal
- Асинхронная коммуникация
- Кафка та же самая
- Взаимодействие с нестабильными API

А в следующий раз я расскажу, как улучшить описание своих обязанностей, рассказывая о них через призму достижений

Обещаная история, правда от Жени.

Однажды прихожу на обычный технический собес, меня встречают обычный разраб + менеджер типа тимлида. Задают обычные технические вопросы. Тимлид для вежливости спросил, чем я занимался до этого, я также из вежливости перечислил несколько проектов. Его заинтересовал один, и я начал рассказывать, как мы его запускали: выявляли потребности клиентов, проектировали, пилили, внедряли, решали трудности и как радовались первому контракту на миллион баксов! И это при том, что я был старшим бекенд-разрабом (да, кстати, если вы считаете, что разработка — это синоним к слову программирование, то у меня для вас плохие новости). Тимлид слушал, открыв рот, а к вечеру я получил оффер. Ни на один технический вопрос я так и не ответил, мне их просто не успели задать.

Почему так получилось
- Я рассказывал про свой опыт через призму достижений, а не «ну, месил там всякое и ел, что дают».
- На предварительных созвонах я задавал наводящие вопросы, а потому понимал, в каком состоянии находится команда нанимателя, какие у них есть проблемы. На очном собеседовании я рассказал о своём опыте решения таких проблем.
- Добавил немного циферок: сколько чего заработали, какой экономический эффект был нанесён.
- Рассказал, как брал инициативу и решал поступающие проблемы, а не просто ждал, пока мне нарежут таски. Это добавило мне очков.

В итоге мне не пришлось отвечать про кишочки JVM, которые я, конечно же, не помню, а получилось обойти духоту и получить оффер. Ничего сложного в этом нет, пользуйтесь.

Про рак убивающий чатGPT
 
Пока нам обещают, что ИИ вот-вот заменит кожаных мешков, я последние несколько месяцев наблюдаю следующую тенденцию:

- В коде появились куски, сгенеренные жпт или чем-то подобным. При этом они такие упоротые, что диву даёшься. Их словно вставили неглядя, без оценки адекватности
- В требованиях тоже появились куски, сгенеренные чатом жпт, сходного качества
- То же самое наблюдаем в важных документах и презах. Понятно, что эти доки никто не читает обычно, но всё же…

Даже и не знаю, что и сказать. Вот вы вставляете код прямо из жпт? И если да, то что вами движет?

Собеседование — это продажа

Вот недавняя история про сабж.
Мы выбирали learning management system (LMS) для клиента. А такие продукты продают, как в кино, на очной презентации: вы оставляете почту на сайте, вам назначают встречу, и профессиональный продажник с вами общается. Все встречи проходят по одному сценарию. Сначала они узнают, что именно вам нужно, а потом рассказывают, как их уникальный продукт закрывает ваши индивидуальные потребности.

Но вот на той встрече всё было иначе. Пришёл японский дед и давай грузить фишками системы: как её можно устанавливать, какая она универсальная и гибкая, для всего вообще. Он даже не спросил, зачем она нам, а мы так и не поняли, делает ли система то, что нужно конкретно нам.

И тут меня осенило: ведь на собеседованиях мы делаем то же самое. Мы приходим и начинаем свой роковой танец с кейсами, не интересуясь, какую боль наниматели хотят закрыть. Хотя, очевидно, что прошлые подвиги могут быть нерелевантны текущей задаче.

Конечно, принимающая сторона тоже хороша: вместо того, чтобы рассказать о насущном, начинают загадывать ребусы и гонять по алгоритмам и дебрям кафок. Но их поведение мы изменить не можем, а своё — вполне.

Так что вот вам ключевой совет из нашего курса: ставьте себя на место работодателя. Попробуйте понять, какую боль он решает и покажите, как сможете решить эти проблемы на примерах того, как решали их раньше.
В следующем посте приведу пример, stay tuned.

Почему вы хотите работать у нас?

Продолжаем тему того, что фокусироваться нужно не на презентации своих самых выгодных сторон, а на решении проблем работодателя.

Вас спрашивают: почему вы хотите у нас работать?

И вы отвечаете:
- Мне понравилась ваша миссия
- У вас интересные задачи
- Мне нужно больше денег, а на текущем месте больше не дают

Все ответы плохи, кроме третьего: он ужасен. И все три ответа выдают вашу сосредоточенность на себе. В этих ответах нет пользы для компании.

Хороший ответ ложится во фреймворк:
Потому что вам нужно X, а я это уже делал, вот доказательства, и вам я это сделаю дешевле/лучше/быстрее других
В крайнем случае:
Потому что вам нужно X. Его я не делал, зато делал X’, X’’ и X’’’. Вот список моих достижений, которые прямо показывают, что я отлично справлюсь и с X

Так, вы из абстрактного разработчика превращаетесь в человека, который решит проблемы работодателя. А за решение конкретной боли можно и заплатить побольше.

Конечно, на интервью себя в деле не покажешь, но показать экспертизу вполне реально. Это мы учим на нашем курсе: как готовится к интервью и как отвечать на вопросы, чтобы не выглядеть японским дедом из предыдущего поста.
Курс запустим через 2 недели! Stay tuned!

Моя коллега в Thoughtworks по имени Йю недавно пожаловалась, что уже на грани выгорания: клиент, с которым она работает, не принимает ни одно её изменение, словно в коде проекта нет проблем. Хуже того, он ещё жалуется в Thoughtworks, обвиняя Йю в саботаже. Мол, она спорит по пустякам, а не таски делает.

Я давно знаю Йю. Она — типичный Thoughtworker старой школы: мастер своего дела и перфекционист. Так что я решил выяснить, кто клиент.

А клиентом оказался очень старый и очень традиционный китайский банк. Там, ясное дело, верят, что у них идеальные процессы, которые можно не менять до конца времён. Каждый чих обсуждается специальным комитетом и проходит 5 уровней согласования. А главное, там уже работает два десятка специалистов Thoughtworks, они всем довольны и уходить не планируют.

Так что проблема не в клиенте и не в Йю. Проблема в несовпадении типа компании и мотивации человека.
Йю как лорд Варис из Игры престолов: стремится сделать всё правильно, изящно, умно и любой ценой. А клиент — образец восточной корпорации, для них главное, чтобы было по регламентам, стабильно и надёжно. Ни в том, ни в другом ничего плохого нет, просто корпорация хочет одного, а человек в ней — совсем другого.

В итоге я за 15 минут объяснил Йю матрицу типов корпораций и мотивации людей, как их отличать, а также почему другие ребята из Thoughtworks вполне довольны китайским банком. Йю стало легче жить, а банковская иммунная система прекратила считать её вирусом.

Здесь я эту матрицу рассказывать не буду, приходите на онлайн-встречу со мной и Евгением. Расскажем, что движет разными разработчиками и как выбрать компанию мечты.

Встреча в четверг, 27 июня, в 19:00 по Москве.
Записывайтесь у бота, он вам напомнит и скинет ссылку

Продолжение про мою коллегу Йю, которая как лорд Варис.

Матрица, которую мы с Йю разобрали, говорит, что если ты хочешь продвигать изменения — выбирай компании с типом управления «стартап». Там перемены принимают охотнее.

Но в стартапах есть свои риски. И я даже не про то, что они прогорают и банкротятся, а вы тратите несколько лет, за которые можно было карьеру построить в другом месте. Важнее, что не всё, что называется стартапом, является им по сути. Я имею в виду тип управления — то, как в компании смотрят на перемены, принимают решения и организуют команду.

Если не научиться определять тип управления, можно запросто попасть в молодую компанию, которая на словах стремится изменить мир, но на деле уже закостенела и стала микрокорпорацией с альянсами и старослужащими.

Как отличить графа Толстого ото льва простого — разбираем в этот четверг на онлайн-встрече.
Записывайтесь у бота, он вам напомнит и скинет ссылку

Дружесская встреча уже через 3 часа! На повестке дня
— Какова ваша мотивация?
— Что вами движет?
— Что даёт удовлетворение от работы?
— Как использовать свои мотивы для построения карьеры?
Обо всём этом мы поговорим на открытом уроке из нашего нового курса «Как построить карьеру в IT». Приходите сегодня в 19:00 по Москве.
Регистрируйтесь!

Самое ценное что я получил за 5 лет в Thoughtworks — это внутренние стандарты разработки. Называются они Sensible Defaults.

Стандарты описывают, как должен выглядеть любой проект TW и кто чем должен заниматься:
PM — служить команде разработки и устранять проблемы до их зрелости, а не колбаски в ганте рисовать
Аналитики — задавать неудобные вопросы заказчику и переводить ответы на язык бизнес-логики
Разработчики — использовать TDD, работать в парах и настроить деплой в прод ещё до кода

Почитайте, если вам интересно, чего там ещё такого, что позволяет TW чарджить консультантов в 2 раза дороже конкурентов. Благо теперь Sensible Defaults доступны всем желающим

Встреча-обсуждение Sensible Defaults 15 Июля (ПН) 19:00

В следующий Понедельник, 15 Июля в 19:00 собираемся на стрим обсуждать Sensible Defaults: кодекс поведения четких разработчиков.
В этот раз начнем с разрабов, секьюрити и девопса
Формат: Встрерча в Zoom, бурное обсуждение. Лимит 1.5 часа, приносить свое пиво, чай, кофе. Приготовьтесь живо участвовать в обсуждении!

Записываться у бота

Кто уже в последних 14%? Мы вот уже близко.

Сережа, правда, на бахчу еще не согласен. Видимо не довыгорел еще

Новый поток курса Разработка без боли и сожалений. стартует уже 26 июля!

- На нем детеально разбираем DDD на реальном коммерческом проекте,
- Разбираем как чистая Архитектура работает в настоящем приложени.
- На созвонах в Зуме разбираем сложные темы такие как TDD, построение CI
- Работаем с настоящим экпсертом на event storming’е

До 26 июля скида 20т.р.
Записываться тут!
По возникшим вопросам обращаться к @dubrova_a
Увидимся!

Паттерны поведения: суетолог
Из личных наблюдений за коллегами

Главная особенность. Когда что-то идёт не так, суетолог не разбирается в причинах и обстоятельствах, а сразу начинает паниковать, дергаться и наводить суету.

Проблема. Суетливые метания не помогают решать проблему, а лишь истощают внимание, накручивают вас и злят окружающих.

Пример 1. Человек написал код, и у него вдруг перестал проходить сквозной GUI-тест. В тесте написано: тут таймаут, кнопку не видим.
Но вместо того, чтобы посмотреть скриншот и зайти в приложение, начинается перезапуск тестов 1000 раз, попытки откатить код и т.д. без попыток понять, что происходит и в чем дело. А дело было в протухшем токене от внешней интеграции, что диагностируется за 10 секунд.

Пример 2. «А-а-а! Локальный стенд не работает» и те же самые телодвижения. А надо было всего лишь внимательно почитать лог запуска и в последней строке увидеть, что у докера закончилось место.

Противодействие. Если у вас что-то не получается, не запускается или не работает, просто отойдите на 10 минут от компьютера, подумайте как вы можете диагностировать проблему и вернитесь обратно. Сэкономите кучу времени себе и окружающим.

До Thoughtworks Сингапура докатился кризис, и меня сократили.

Реалити-шоу “Сможет ли Сережа найти работу за 2 месяца” начинается!

Через 2 месяца я обязан забрать детей из школы, сдать квартиру и покинуть Сингапур. Или найти новую работу. :)

Буду вести трансляцию в канале!

Впечатления пока следующие:

• Откликаться на вакансии – дело очень утомительное и бесполезное. Пока 0 собеседований. Как только вакансия открывается, в первый же день туда поступает более 100 заявок.
• Networking работает. Если видишь открытую вакансию и можешь найти хоть кого-то, кто может напрямую закинуть твоё резюме HR’у, то шансы попасть на собеседование возрастают на порядок (да, в 10 раз). А если вас могут ещё и порекомендовать, то это увеличивает шансы прийти на интервью практически до 100%.

1 августа 19:00 по мск “Learning Domain-Driven Design Часть II. Тактический замысел (Глава 5-7) / Евгений Лукьянов”

Продолжаем разбор книжки по DDD. Переходим от стратегии к тактике: будет дан ответ на вопрос «Как проектировать программное обеспечение?». В главах 5–7 будут рассмотрены паттерны реализации бизнес-логики, позволяющие программному коду «говорить» на едином языке ограниченного контекста. В этих главах обсуждаются простые паттерны, такие как транзакционный сценарий и активная запись (глава 5), сложные паттерны, такие как модель предметной области (глава 6), и её расширение с учётом фактора времени (глава 7).

Помогать в обсуждение нам будет - Евгений Лукьянов 🔥 Архитектор ПО, практикующий адепт DDD. Ведет канал https://www.tg-me.com/StringConcat разработка без боли и сожалений/com.stringconcat

Подключайтесь в четверг в 19:00 к обсуждению в Zoom или к YouTube трансляции

А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Жене ⤵️

Для тех кто вчера не смог — по ссылке на ютуб доступна запись